Identity - Based Encryption Instructor : Chris

Encryption in which “your name is your public key” is called Identity-Based Encryption (IBE). Shamir’s original motivation for identity-based encryption was to simplify the management of public keys. Frequently, this process can be unwieldy because of the following problem: if Bob obtains Alice’s public key over the network, how does Bob know that the key really belongs to Alice, and not to a malicious adversary-in-themiddle who replaced Alice’s key with his own as it traveled over the network? The usual solution is to rely upon “certificate authorities” (CAs), who are trusted to implement the following process: when Alice creates a key pair, she presents her public key pkA and some valid form of identification to the CA. The CA then generates a signature, under its own verification key vkCA, attesting to the statement “this public key pkA belongs to Alice,” which Alice appends to her own public key. Later on, Bob can verify the CA’s signature and gain confidence that the key really is Alice’s. Of course, in order to do this Bob needs to know the CA’s true public key (and to trust that the CA implemented its policy correctly), so at first sight it seems that we have gained very little. However, there need only be a few CAs in the world, and they can make their keys widely known through alternative means, such as bundling with common cryptographic software or widespread publication. Still, this whole process is rather heavyweight: every time a person generates a new public key, she must register that key with a CA, and Bob must store and manage a large number of keys for all the people with whom he corresponds. (Things become even more complicated when we introduce revocation, where Alice may desire for her key to be declared invalid if, for example, it becomes compromised.) Identity-based encryption can simplify the above scenario in the following way: for a particular administrative domain (e.g., domain.com), there is an “authority” who generates a “master” public/secret key pair for the entire domain. When Bob wants to send a message to Alice at [email protected], he simply encrypts using the public key string alice and the master public key for the domain (which should be certified as usual). There is no need for Bob to obtain Alice’s individual public key or certificate, or even for Alice to generate a key at all! Meanwhile, Alice identifies herself to the domain authority, who uses its master secret key to “extract” a secret key that works just for the identity alice. Alice uses this to decrypt her message as usual. Notice here that the authority implicitly knows secret keys for every user in the system, so it can read everyone’s encrypted messages. Depending on the scenario, this can be a blessing or a curse, but in any case authority’s master secret key is very powerful, so it must be guarded carefully. IBE also provides additional useful properties like implicit revocation (via identities that have an “expiration date” appended to them) and delegation (only a subset of messages can be decrypted by a particular agent). More generally, IBE-related techniques and implications have proved to be very versatile and powerful in the design of other important and seemingly unrelated protocols. The problem of constructing an IBE remained open for many years following its initial conception by Shamir. Finally in 2001, Boneh and Franklin described a scheme that used a relatively new mathematical object called a bilinear map (which has since been shown to have numerous other related applications). Soon after Boneh and Franklin’s announcement, it was revealed that Clifford Cocks, a mathematician in the United Kingdom’s cryptography agency GCHQ, had years earlier devised a simple IBE based on a standard and elementary assumption (but his scheme was classified by the UK government). This was an interesting case